1. Technical Field
The present invention relates to an improved data processing system and, in particular, to a method and apparatus for optimizing performance in a data processing system. Still more particularly, the present invention provides a method and apparatus for a software program development tool for enhancing performance of a software program through software profiling.
2. Description of Related Art
In analyzing and enhancing performance of a data processing system and the applications executing within the data processing system, it is helpful to know which software modules within a data processing system are using system resources. Effective management and enhancement of data processing systems requires knowing how and when various system resources are being used. Performance tools are used to monitor and examine a data processing system to determine resource consumption as various software applications are executing within the data processing system. For example, a performance tool may identify the most frequently executed modules and instructions in a data processing system, or may identify those modules which allocate the largest amount of memory or perform the most I/O requests. Hardware performance tools may be built into the system or added at a later point in time. Software performance tools also are useful in data processing systems, such as personal computer systems, which typically do not contain many, if any, built-in hardware performance tools.
One known software performance tool is a trace tool. A trace tool may use more than one technique to provide trace information that indicates execution flows for an executing program. One technique keeps track of particular sequences of instructions by logging certain events as they occur, so-called event-based profiling technique. For example, a trace tool may log every entry into, and every exit from, a module, subroutine, method, function, or system component. Alternately, a trace tool may log the requester and the amounts of memory allocated for each memory allocation request. Typically, a time-stamped record is produced for each such event. Corresponding pairs of records similar to entry-exit records also are used to trace execution of arbitrary code segments, starting and completing I/O or data transmission, and for many other events of interest.
In order to improve performance of code generated by various families of computers, it is often necessary to determine where time is being spent by the processor in executing code, such efforts being commonly known in the computer processing arts as locating xe2x80x9chot spots.xe2x80x9d Ideally, one would like to isolate such hot spots at the instruction and/or source line of code level in order to focus attention on areas which might benefit most from improvements to the code.
Another trace technique involves periodically sampling a program""s execution flows to identify certain locations in the program in which the program appears to spend large amounts of time. This technique is based on the idea of periodically interrupting the application or data processing system execution at regular intervals, so-called sample-based profiling. At each interruption, information is recorded for a predetermined length of time or for a predetermined number of events of interest. For example, the program counter of the currently executing thread, which is a process that is part of the larger program being profiled, may be recorded during the intervals. These values may be resolved against a load map and symbol table information for the data processing system at post-processing time, and a profile of where the time is being spent may be obtained from this analysis.
For example, isolating such hot spots to the instruction level permits compiler writers to find significant areas of suboptimal code generation at which they may thus focus their efforts to improve code generation efficiency. Another potential use of instruction level detail is to provide guidance to the designer of future systems. Such designers employ profiling tools to find characteristic code sequences and/or single instructions that require optimization for the available software for a given type of hardware.
Continuous event-based profiling has limitations. For example, continuous event-based profiling is expensive in terms of performance (an event per entry and per exit), which can and often does perturb the resulting view of performance. Additionally, this technique is not always available because it requires the static or dynamic insertion of entry/exit events into the code. This insertion of events is sometimes not possible or is often difficult. For example, if source code is unavailable for the to-be-instrumented code, event-based profiling may not be feasible. However, it is possible to instrument an interpreter of the source code to obtain event-base profiling information without changing the source code.
On the other hand, sample-based profiling provides only a xe2x80x9cflat viewxe2x80x9d of system performance but does provide the benefits of reduced cost and reduced dependence on hooking-capability. Further, sample-based techniques do not identify where the time is spent in many small and seemingly unrelated functions or in situations in which no clear hot spot is apparent. Without an understanding of the program structure, it is not clear with a xe2x80x9cflatxe2x80x9d profile how to determine where the performance improvements can be obtained.
Therefore, it would be advantageous to provide a system that combines the benefits of event-based profiling with the benefits of reduced system perturbation in sample-based profiling. It would be particularly advantageous to provide the ability to enable and disable profiling of selected portions of a data processing system and to combine the output from different profiling periods into a single merged presentation.
A method and system for profiling a program using periodic trace sampling is provided. During the execution of the program, sample-based profiling of the executing program is performedxe2x80x94for a predetermined period, a profiler performs trace processing for the program, after which the profiler pauses and does not perform trace processing for a predetermined period or only performs lightweight processing for a predetermined period. The periods controlling the profiler may be selected by a user, and the periods may be measured by temporal or non-temporal metrics. The user may also specify parameters that are used to filter events so that profiling is performed only for specified threads or methods. The profiler cycles through these periods, during which selected events are processed to generate a profile of the execution flows within the program. For each sample period, a tree data structure is generated in which nodes of the tree data structure represent the routines of the program that execute during the sample period, as may be indicated by entry and exit events caused by the execution of the routines. At the start of each sample period, execution flow information may be used to create an initial tree data structure. When the execution of the program is complete, the tree data structures from each sample period are merged into a resulting tree data structure.